Release 10.1A: OpenEdge Development:
Progress Dynamics Basic Development

Other SBO issues

This section describes the following SBO issues:

SBO as navigation-target.
Locating a contained data object.
SDO programming interface in the SBO.
SBO as data-target.

SBO as navigation-target

An SBO can be a Navigation-Target. Since you might want to navigate more than one of the contained SDOs, it is necessary to allow the Navigation-Source (SmartToolbar) to specify which SDO is to be associated with this Navigation-Source without changing the existing interface between these objects. (See the "Brokering SDO data in an SBO" section for more information.) To accomplish this, there is a new property for the Panel class used by toolbars called NavigationTargetObject, which can optionally be set to the ObjectName of an SDO. NavigationTargetObject is an instance property. When the Instance Property dialog box is run, this property is displayed as a drop-down list and enabled if the Navigation-Target is an SBO (that is, if it is an object that has a ContainedDataobjects property). Otherwise it is disabled. If it is not explicitly set, the default is to pass the Navigation link on to the MasterDataObject. Use this value to create an entry pair in the SBO ObjectMapping property associating the two objects, so that the SBO knows which SDO to pass Navigation events.

Locating a contained data object

Generally, you should consider the SBO to be reasonably opaque, so that it accepts requests from other objects and coordinates those with the contained SDOs. However, it is not possible to do this in every case, as that would unnecessarily complicate the API of the SBO. The SBO supports a function called dataObjectHandle, which takes an ObjectName as an input parameter and returns the procedure handle of that SmartDataObject. You can use this handle for a client object that needs to communicate directly with an SDO. The majority of the SDO programming interface, however, is duplicated in the SBO so that generally a client object can run the same routines in an SBO that it would in an SDO, and have the SBO pass the call on to the appropriate contained objects.

SDO programming interface in the SBO

Most of the common routines in the SDO are also supported with the same calling sequence in the SBO support code (in sbo.p or sbo.i). This allows application code to treat an SBO like a compound SDO in many ways. For example, a general restriction in some of the calls where column names are an input parameter, as described for addQueryWhere and assignQuerySelection, is that you must qualify column names by the SDO ObjectName. Generally, the SBO identifies the SDO associated with the caller by using the ObjectMapping property. It passes the call on to that object, or else uses property data defined within the SBO to satisfy the request. Here is a list of SDO internal procedures and functions duplicated in the SBO’s API (in all cases, the calling sequence is the same).

The internal procedures that are duplicated are:

commitTransaction, undoTransaction
dataAvailable
fetchBatch, fetchFirst, fetchNext, fetchPrev, fetchLast
initializeObject

The functions that are duplicated are:

addQueryWhere, assignQuerySelection
addRow, copyRow
columnDataType, columnLabel, columnColumnLabel, columnExtent, columnFormat, columnHelp, columnInitial, columnColumnLabel, columnMandatory, columnModified, columnPrivateData, columnQuerySelection, columnReadOnly, columnStringValue, columnTable, columnValExp, columnValMsg, columnValue, columnWidth, columnDbColumn
colValues (can take either qualified or unqualified column names)
deleteRow, cancelRow
openQuery
submitRow

SBO as data-target

An SBO can be a Data-Target for an SDO just as another SDO can. It has the ForeignFields property, which lets you specify fields to use as foreign keys, and the ForeignValues property, which stores the current values for those fields. The ForeignFields will always be applied to the SBO’s MasterDataObject. You cannot currently use the SBO as a Data-Source for another SBO.